Network assessment tools referred to as “analyzers” are often relied upon to analyze networks communications at a plurality of layers. One example of such analyzers is the Sniffer® device manufactured by Network Associates®, Inc. Analyzers have similar objectives such as determining why network performance is slow, understanding the specifics about excessive traffic, and/or gaining visibility into various parts of the network.
In use, network analyzers often take the form of a program that monitors and analyzes network traffic, detecting bottlenecks and problems. Using this information, a network manager can keep traffic flowing efficiently. A network analyzer can also be used legitimately or illegitimately to capture data being transmitted on a network. For example, a network router reads every packet of data passed to it, determining whether it is intended for a destination within the router's network or whether it should be passed further along the Internet. A router with a network analyzer, however, may be able to read the data in the packet as well as the source and destination addresses. It should be noted that network analyzers may also analyze data other than network traffic. For example, a database could be analyzed for certain kinds of duplication, etc.
Network communication between network devices takes place according to communication protocols, i.e., sets of rules that are agreed upon for the communication which the network devices taking part in the network communication must observe. For monitoring communication networks, and particularly for testing communication networks following the replacement of a network device or the extension of the network by further network devices, network analyzers must be able to decode the network communications in light of the protocol used.
Prior art FIG. 1 illustrates one known prior network analyzer methodology 10. As shown, a plurality of packets 12 are collected and stored in a capture file for subsequent analysis. A shown, such packets 12 include both request packets and reply packets. In use, both the request and reply packets must be decoded in order to properly analyze an associated network. Unfortunately, information that is often required to adequately decode the reply packets is only resident in the associated request packets. Thus, it is necessary to correlate the request and reply packets, before network communications may be analyzed.
In order to accomplish this in the context of the present network analyzer methodology 10 of FIG. 1, source and destination information 14 associated with a data link control (DLC) layer of the packets 12 is monitored and tracked for the purpose of identifying request packets associated with reply packets, so that all of the information is available for proper decoding of the reply packets.
Prior art FIG. 1A illustrates a problem 20 that arises when correlating request and reply packets using the network analyzer methodology 10 of FIG. 1. As shown, a request packet may be sent utilizing a first physical circuit 22, while an associated reply packet is received on a second physical circuit 24. This phenomena often results from the use of various load-balancing techniques known in the art, and is becoming more and more prevalent. Further, this type of occurrence happens prevalently in the context of broadcasting and multicasting.
Unfortunately, the network analyzer methodology 10 of FIG. 1 breaks down as a result of the phenomena set forth in FIG. 1A. In particular, the first physical circuit 22 and the second physical circuit 24 involve different switches 26 which, in turn, have different addresses. To this end, the source and destination information associated with the DLC layer is different for the request and reply packets. Thus, the correlation technique of the network analyzer methodology 10 of FIG. 1 no longer works properly.
There is thus a need for a technique of correlating request and reply packets in the context of analyzing networks which overcomes the problems of the prior art.